Within the 3rd Generation Partnership Project (3GPP) work is currently ongoing on UTRAN long term evolution (LTE). System Architecture Evolution/Long Term Evolution (SAE/LTE) architecture that moves PDCP, user plane ciphering and header compression to the enhanced Node B (eNB) changes the needs for handling the length of S1-U (and X2-U) frames as the length of the S1-U (and X2-U) frame then is considerably increased. Therefore appropriate solutions to deal with the length of Maximum Transmission Unit (MTU) are necessary. At the same time capabilities to minimise the probability of S1-U frame being fragmented have been somewhat increased.
The following problems relate to fragmentation:
Transport overhead: Every fragment includes an additional IP header; hence it adds additional transmission overhead. It is 20 octets (though depending on the usage of optional headers) per fragment and in case of IPv4 and, in case of IPv6, 48 octets (i.e. 40 octets of standard IPv6 header plus 8 octets of the fragment header). A typical transport layer datagram would be carried in 2 fragments. Therefore, a selection of length of transport layer datagram so that it fits into single IP packet provides significantly lower aggregate overhead.
Incomplete discard: In case packets are discarded due to congestion it is very likely that fragments of the same datagram are discarded independently. Hence transport network resources are used to forward data that will be discarded at the receiver, the Serving Gateway (SGW) or eNB. In case of severe congestion it could lead to further discarding and hence more incomplete datagrams.
Processing efficiency: It is generally accepted that the S1 interface is the bottleneck. Therefore considerable packet loss and delay variation could be present for interactive and best effort flows even in a normal condition in order to maximise the end-user perceived data rate and utilisation of scarce S1 resources. This may require significant processing effort and relatively long-term memory reservation for reassembly of the original datagrams in the receiver as the reassembly buffers have to be allocated for at least for the length of perceived delay variation on the applicable transmission path.
Security threat: It should be noted that typical implementations assume that only fraction of datagrams are fragmented and, if the datagrams are fragmented, the fragments arrive with very short interval. That allows for limitation of the memory required for reassembly. Therefore, transmission of incomplete datagrams is a common way to introduce denial of service attacks as scarce reassembly buffers are consumed for extensive periods and legitimate fragmented datagrams could be discarded due to lack of reassembly buffers/engines. Although this is not really a problem for (logical) SGW and eNB as those nodes use secure network, it could be a problem for security gateways (SEG) in case the fragmentation is performed on the path between SEG-s.
False reassembly: The identification header used for reassembly is only 16 bits in case of IPv4 (32 bits in case of IPv6). Considering the peak data rate, measured in packets per second, there is high probability of the wrap around of the ID and therefore incorrect reassembly (though this also depends on the setting of the reassembly timer at the receiver). The false reassembly results in at least further data loss that may be detected by the receiver or even an integrity (and potentially confidentiality) violation.
Hence there exists a need for a system architecture that removes or at least reduces the problems relating to fragmentation.